Глава 7. Автономный сервер

Автономный сервер ‑ это специальное серверное приложение, которое предназначено для обеспечения работы с информационной базой управляемого приложения любого клиентского приложения и Конфигуратора. Взаимодействие клиентского приложения и автономного сервера возможно как про протоколу HTTP, так и по протоколу TCP/IP (определяется настройками автономного сервера). В каждый момент времени автономный сервер позволяет работать с одной базой данных. Для работы с разными базами данных поддерживается возможность одновременной работы нескольких экземпляров автономного сервера. В качестве базы данных может выступать как база данных одной из поддерживаемых СУБД, так и файл 1Cv8.1CD.

Автономный сервер содержит встроенный веб-сервер. Поэтому для публикации информационной базы не требуется наличие внешнего (по отношению к системе «1С:Предприятие») веб-сервера.

Автономный сервер предоставляет перечень возможностей, которые, в основном, совпадают с возможностями кластера серверов той же версии (в том числе и при работе с файловым вариантом информационной базы). Перечень ограничений и особенностей автономного сервера см. здесь. Средства администрирования и управления автономного сервера существенно различаются с таковыми инструментами кластера серверов. Эти отличия также см. здесь. Для администрирования автономного сервера предназначена специальная утилита командной строки ibcmd.

Автономный сервер является приложением (ibsrv), в котором реализовано все необходимое для работы сервера «1С:Предприятие». При своей работе автономный сервер использует компоненты установленного экземпляра системы «1С:Предприятие» своей версии.

Смотри также:

● Командная строка утилиты администрирования (см. здесь).

● Командная строка автономного сервера (см. здесь).

Автономный сервер не поддерживает следующие возможности:

● Обслуживание нескольких информационных баз одним автономным сервером.

● Работу нескольких автономных серверов с одной информационной базой.

● Работу с обычным приложением. Автономный сервер может обслуживать только информационные базы управляемого приложения.

● Использование инструментов автономного сервера (сам автономный сервер, утилита управления сервером) с информационными базами, которые в данный момент работают под управлением кластера серверов системы «1С:Предприятие». Попытки такого использования могут приводить к разрушению базы данных, с которой выполняются такие действия.

● Работу с информационной базой с использованием внешнего соединения (COM-соединение).

● Использование СУБД Microsoft SQL Server в том случае, когда автономный сервер работает под управлением ОС Linux.

● Управление автономным сервером с помощью сервера ras.

● Для автономного сервера отсутствуют графические инструменты управления (аналог консоли кластера).

● Использование фоновой реструктуризации.

● Управление сервером с помощью COM-объекта V83.ComConnector.

● Работу по протоколу HTTPS. Для работы с автономным сервером по протоколу HTTPS требуется использование произвольного веб-сервера, который работает в режиме reverse proxy и предоставляет клиентскому приложению возможность работы по протоколу HTTPS.

● Использование аутентификации операционной системы.

● Работу с системой «1С:Аналитика».

● Использование сервисов интеграции.

● Использование ботов системы взаимодействия.

● Загрузку конфигурации из XML-файлов, которые были выгружены в линейном формате.

Системные требования автономного сервера аналогичны системным требованиям кластера серверов «1С:Предприятие» (в том числе и при работе с файловым вариантом информационной базы). Из этого правила существуют исключения:

● Автономный сервер не работает под управлением 32-разрядных ОС семейства Windows.

Автономный сервер устанавливается одновременно с кластером серверов «1С:Предприятия». Отдельных действий для установки автономного сервера выполнять не требуется.

Запуск автономного сервера и утилиты управления сервером выполняется из командной строки. Все необходимые параметры требуется указывать в конфигурационном файле автономного сервера или в командной строке запуска. Вывод информации о выполнении заданного действия осуществляется в стандартный поток вывода (stdout). В случае успешного завершения код возврата будет равен значению 0. В противном случае код завершения будет отличен от 0 и сообщения об ошибке будут помещены в стандартный поток ошибок (stderr).

Документация содержит описание командной строки как сервера (см. здесь), так и утилиты администрирования (см. здесь). Однако, и сам автономный сервер и утилита управления сервером содержат встроенную справочную систему. Для получения справочной информации следует использовать следующий вариант запуска утилит:

ibsrv help
ibcmd help

Если требуется получить описание выбранного режима работы утилиты управления сервером (в примере будет показана справка по режиму server), то для этого можно использовать команду вида:

ibcmd help server

Чтобы сохранить справочную информацию для дальнейшего использования, можно воспользоваться средствами операционной системы по переадресации стандартного потока вывода:

ibcmd help server > .\server.desc

При работе автономного сервера (ibsrv), подключение к базе данных осуществляется в разделяемом режиме.

Смотри также:

● Командная строка автономного сервера (см. здесь).

● Командная строка утилиты администрирования (см. здесь).

Автономный сервер может быть запущен как обычное приложение операционной системы, а также как сервис операционной системы (для ОС Windows) или в режиме демона (для ОС Linux).

Автономный сервер не предоставляет встроенных инструментов для регистрации себя в качестве сервиса операционной системы. Также не предоставляются средства управления (запуск и останов) сервисом. Для этих операций необходимо использовать средства операционной системы (утилиту sc).

Конфигурационный файл автономного сервера предназначен для указания параметров экземпляра автономного сервер. Конфигурационный файл используется как самим сервером, так и утилитой администрирования. Некоторые параметры сервера могут быть заданы и через командную строку (как самого сервера, так и утилиты управления) и через конфигурационный файл, однако, конфигурационный файл позволяет управлять всеми параметрами автономного сервера, кроме путей расположения служебных каталогов автономного сервера (см. здесь). Для конфигурационного файла автономного сервера не существует расположения по умолчанию, поэтому при каждом запуске автономного сервера (или утилиты управления) необходимо явным образом специфицировать расположение этого файла. Конфигурационный файл автономного сервера формируется в формате YAML, а его описание см. здесь.

При запуске автономного сервера следует помнить о следующих особенностях:

● При запуске автономного сервера параметры, необходимые для его (сервера) работы определяются следующим образом:

● Получаются значения всех параметров, которые заданы в командной строке запуска.

● Выполняется попытка получить значения оставшихся параметров с помощью конфигурационного файла сервера.

● Если с помощью конфигурационного файла сервера не удалось получить значения оставшихся параметров ‑ будут использованы значения по умолчанию.

● Значения параметров, указанные в командной строке запуска, имеют приоритет над значениями из конфигурационного файла.

● Конфигурационный файл сервера создается или специальной командой (ibcmd server config init) или полностью вручную.

● С одним каталогом данных в один момент времени может работать или один экземпляр автономного сервера или одна утилита управления сервером. Указывать каталог данных (параметр --data) обязательно при одновременной работе нескольких копий автономного сервера, а также при выполнении практически любой операции с автономным сервером.

● С одной базой данных в каждый момент времени может работать только одно приложение из следующего списка:

● Автономный сервер.

● Утилита управления автономным сервером (в offline-режиме).

● Кластер серверов «1С:Предприятие».

● Клиентские приложения, работающие с файловым вариантом информационной базы при прямом подключении (не через автономный сервер).

При описании командной строки запуска предполагается, что запуск выполняется из каталога bin необходимой версии системы «1С:Предприятие».

Выполняется запуск автономного сервера для работы с файловым вариантом информационной базы, каталог данных которой расположен в папке c:\db\ss-data\demo. Все параметры работы автономного сервера в этом случае будут установлены в значения по умолчанию.

ibsrv --data="c:\db\ss-data\demo"

В частности, сам файл информационной базы (1Cv8.1CD) будет искаться в каталоге c:\db\ss-data\demo\db-data.

Если запустить автономный сервер совсем без параметров, то автономный сервер выполнит попытку запуска с файловым вариантом информационной базы, которая расположена в каталоге данных по умолчанию.

Выполняется запуск автономного сервера для работы с клиент-серверным вариантом информационной базы, имеющей следующие параметры:

● Используется СУБД Microsoft SQL Server.

● Для доступа к СУБД будет использоваться пользователь dbUser с паролем dbUserPassword.

● База данных имеет имя в СУБД dbName.

● Предполагается, что база данных существует и действительно является базой данных «1С:Предприятия».

ibsrv --dbms=mssqlserver --database-server=dbServerName --database-user=dbUser --database-password=dbUserPassword --database-name=dbName --data="D:\ss-data\dbName-data"

Если при запуске автономного сервера не указаны обе команды (--database-path и --dbms), то автономный сервер будет запущен с файловой информационной базой, которая размещается в следующем каталоге:

● ОС Linux: ~/.1cv8/standalone-server/db-data.

● ОС Windows: %LOCALAPPDATA%\1C\1cv8\standalone-server\db-data.

Для того чтобы зарегистрировать автономный сервер в качестве службы ОС Windows, можно воспользоваться следующим командным файлом (или взять его за основу для дальнейшей модернизации).

Файл register-ss.bat:

@echo off
rem %1 - полный номер версии 1С:Предприятия
rem %2 - номер экземпляра регистрируемого сервиса
rem %3 - расположение конфигурационного файла сервера
rem %4 - каталог данных информационной базы
set SrvcUserName=<пользователь автономного сервера>
set SrvcUserPwd=<пароль пользователя автономного сервера>
set SrvcName="Standalone server %2"
set BinPath="\"C:\Program Files\1cv8\%1\bin\ibsrv.exe\" --service --config=\"%~3\" --data=\"%~4\""
set Desctiption="1C:Enterprise 8.3 Standalone Server. Parameters: %1, instance #%2, data directory %4"
sc stop %SrvcName%
sc delete %SrvcName%
sc create %SrvcName% binPath= %BinPath% start= auto obj= %SrvcUserName% password= %SrvcUserPwd% displayname= %Desctiption%

При запуске данного командного файла используются следующие параметры:

1. Полный номер версии системы «1С:Предприятие», из который будет использован автономный сервер.

2. Номер экземпляра регистрируемой службы. В приведенном примере не выполняется проверка существования службы с заданным номером. Из-за того, что автономный сервер обслуживает одну базу данных, с помощью данного параметра можно регистрировать свою службу ОС на каждую обслуживаемую информационную базу.

3. Полный путь к конфигурационному файлу данного экземпляра автономного сервера (должен быть заключен в двойные кавычки). В этом конфигурационном файле должны быть размещены все параметры, с которыми выполняется запуск автономного сервера (включая параметры базы данных). Для разных экземпляров сервиса должны быть свои конфигурационные файлы.

4. Полный путь к каталогу данных информационной базы. В данном каталоге размещаются служебные данные информационной базы (журнал регистрации, индекс полнотекстового поиска, временный каталог и т. д.).

Пример запуска командного файла (требуются права администратора):

register-ss.bat 8.3.24.100 2 "d:\1C DB\ss-data\demo\demoma.yml" "d:\ss-data\demoma"

После запуска командного файла с такими параметрами будут выполнены следующие действия:

● Имя службы: Standalone server 2.

● Используемая версия «1С:Предприятия»: 8.3.24.100.

● Командная строка запуска службы: "C:\Program Files\1cv8\8.3.24.100\bin\ibsrv.exe" --service --config="d:\1C DB\ss-data\demo\demoma.yml" --data="d:\ss-data\demoma".

● Отображаемое имя: 1C:Enterprise 8.3 Standalone Server. Parameters: 8.3.24.100, instance #2, data directory d:\ss-data\demoma.

● Режим запуска службы: Автоматический.

В этом случае для управления службой следует использовать следующие команды операционной системы:

● Запуск службы: sc start "Standalone server 2"

● Останов службы: sc stop "Standalone server 2"

● Удаление службы: sc delete "Standalone server 2"

К моменту запуска службы конфигурационный файл должен содержать все нужные параметры для запуска автономного сервера.

Для запуска автономного сервера в режиме демона в ОС Linux следует выполнить следующую команду:

ibsrv --daemon --config="путь к файлу конфигурации" --data="путь к каталогу данных"

К моменту запуска автономного сервера в режиме демона конфигурационный файл должен содержать все параметры, которые потребуются для запуска и работы автономного сервера.

Смотри также:

● Конфигурационный файл автономного сервера (см. здесь).

Клиентское приложение может подключаться к автономному серверу аналогично подключению к кластеру серверов. Для подключения может использоваться как протокол HTTP, так и протокол TCP/IP. При использовании протокола HTTP возможно подключение только клиентского приложения. При использовании протокола TCP/IP возможно использовать как приложение тонкого клиента, так и Конфигуратор.

При подключении по протоколу TCP/IP следует обеспечить точное соответствие между именем информационной базы, которая указывается в параметрах подключения клиентского приложения, и именем информационной базы, которая указана при запуске автономного сервера (команда --name командной строки запуска автономного сервера или соответствующий параметр конфигурационного файла). Если имена различаются ‑ клиентское приложение не сможет подключиться к информационной базы.

Так, пусть автономный сервер запущен (для файловой информационной базы) с помощью следующей командной строки:

ibsrv.exe --name=docs-db --data="D:\ss-data\fs-data"

В этом случае запуск Конфигуратора с помощью командной строки (находясь на том же компьютере, что и работающий автономный сервер) нужно выполнять с помощью командной строки следующего вида:

1cv8.exe designer /S localhost\docs-db

Такой вариант приведет к тому, что будет запущен Конфигуратор, который подключиться к информационной базе, которую обслуживает автономный сервер.

Если каким-либо образом изменить имя информационной базы, например, использовать такую строку запуска:

1cv8.exe designer /S localhost\docsdb

Такой вариант приведет к тому, что будет открыт диалог создания новой информационной базы.

Для подключения тонкого клиента следует использовать строку запуска следующего вида (первая ‑ для подключения по протоколу HTTP, вторая ‑ для прямого подключения к автономному серверу):

1cv8c.exe enterprise /WS"http://localhost:8314"
1cv8c.exe enterprise /S localhost\docs-db

Для запуска веб-клиента будет необходимо указать веб-браузеру URL следующего вида:

http://localhost:8314

Все настройки приведены для состояния по умолчанию. Если параметры публикации изменялись в настройках, то следует отредактировать соответствующую строку запуска таким образом, чтобы она (строка запуска) соответствовала реальным параметрам запуска автономного сервера.

Как было сказано ранее (см. здесь), параметры автономного сервера могут задаваться через конфигурационный файл или с помощью командной строки запуска. При этом конкретный экземпляр управляемого автономного сервера может задаваться несколькими способами:

1. С помощью команды --data командной строки утилиты ibcmd. В этом случае все действия утилиты управления происходят с той информационной базой, которая описывается каталогом данным, указанным в команде --data. Такой режим управления может называться offline-режимом, т. к. для выполнения команд не требуется запущенный экземпляр автономного сервера. Более того, если с каким-либо каталогом данных запущен экземпляр автономного сервера, то offline-режим управления будет недоступен.

2. С помощью команды --pid командной строки утилиты управления ibcmd. В этом случае считается, что утилита управления подключается к запущенному экземпляру автономного сервера, который работает на том же компьютере, где будет работать утилита ibcmd. В этом случае значением команды --pid будет выступать номер процесса операционной системы запущенного экземпляра автономного сервера. Номер процесса указывается в значениях той операционной системы, под управлением которой работает автономный сервер.

Например: --pid 16453.

3. С помощью команды --remote командной строки утилиты управления ibcmd. В этом случае считается, что утилита управления подключается к запущенному экземпляру автономного сервера, который работает на удаленном компьютере. При этом автономный сервер, запущенный на удаленном компьютере, должен быть сконфигурирован таким образом, чтобы предоставлять доступ к информационной базе и собственно серверу по протоколу SSH. Идентификация экземпляра автономного сервера в этом случае выполняется с помощью URL и порта, который обслуживает автономный сервер.

Например: ssh://server1C:8282.

Команду --data (равно как и любые параметры, описывающие параметры доступа к информационной базе) нет необходимости указывать в том случае, если выполняется администрирование «удаленного» сервера, т. к. вся необходимая информация уже есть у автономного сервера (указана в параметрах конфигурационного файла/командной строки запуска ibsrv). Под термином «удаленный» в данном случае понимается администрирование любого запущенного экземпляра автономного сервера с помощью команд --pid или --remote.

При работе с «удаленным» автономным сервером доступны не все команды утилиты управления. Более подробно список недоступных команд приводится ниже, в соответствующих разделах.

При работе с автономным сервером, для выполнения любых команд, которые используют доступ к информационной базе, будет создаваться сеанс информационной базы. Пользователь, от имени которого создается сеанс, должен иметь права на выполнение действия, которое инициируется выполняемой командой. Если команда, отправляемая автономному серверу, не требует доступа к информационной базе, но требует доступа к серверу целиком (например, получение списка сеансов), то выполнение такой команды должно выполняться от имени пользователя, который имеет административные права в информационной базе, обслуживаемой данным экземпляром автономного сервера. Аутентификация выполняется или в интерактивном режиме или с помощью параметров командной строки:

● Указание имени пользователя: --user.

● Указание пароля пользователя: --password.

При администрировании автономного сервера существует ограничение: если какой-либо каталог указан в качестве каталога данных запущенного экземпляра автономного сервере (команда --data), то использование этого каталога не поддерживается в следующих случаях:

● Для запуска другого экземпляра автономного сервера.

● При работе утилиты администрирования в offline-режиме.

Порядок создания сеанса и аутентификации:

● Если доступ производится через удаленное подключение (SSH) ‑ сеанс создается от имени пользователя, аутентифицированого в шлюзе SSH.

● Если доступ производится через локальное подключение (выбран экземпляр автономного сервера на локальном компьютере) или выполняется настройка конфигурационного файла, то сеанс создается от имени системного пользователя «1С:Предприятия», который обладает полными административными правами.

В этом случае для исполнения доступны все команды утилиты управления автономным сервером. Работа возможно только на том же компьютере, что и каталог с данными информационной базы. Не поддерживается одновременная работа автономного сервера и утилиты управления с одним каталогом данных информационной базы (команда --data).

Для управления автономным сервером с помощью утилиты управления доступны все команды этой утилиты, кроме следующих:

● Инициализация конфигурации автономного сервера (все команды группы config).

● Создания информационной базы (команда ibcmd infobase create).

● Восстановления целостности информационной базы (команда ibcmd infobase repair).

Для управления автономным сервером с помощью утилиты управления доступны все команды этой утилиты, кроме следующих:

● Инициализация конфигурации автономного сервера (все команды группы config).

● Создания информационной базы (команда ibcmd infobase create).

● Восстановления целостности информационной базы (команда ibcmd infobase repair).

Когда для автономного сервера включена поддержка SSH, то, дополнительно к серверным возможностям, автономный сервер начинает работать аналогично конфигуратору, запущенному в режиме агента. В этом режиме к автономному серверу (кроме утилиты ibcmd) можно подключаться сторонними SSH- и SFTP-клиентами и выполнять некоторый набор команд. Набор команд, который может выполняться с помощью SSH-клиента, аналогичен набору команд конфигуратора в режиме агента, но поддерживаются только следующие команды:

● help ‑ отображение справки по командам (подробнее см. здесь).

● common ‑ общие команды (подробнее см. здесь):

● connect-ib ‑ подключение к информационной базе.

● disconnect-ib ‑ отключение от информационной базы.

● options ‑ настройки текущей сессии (подробнее см. здесь):

● get ‑ получить значение параметра.

● list ‑ получить список параметров.

● set ‑ установить значение параметра.

● config ‑ команды редактирования конфигурации (подробнее см. здесь):

● dump-cfg ‑ сохранение конфигурации в файл.

● dump-config-to-files ‑ выгрузка конфигурации в XML-файлы.

● dump-external-data-processor-or-report-to-files ‑ выгрузить в XML-файлы внешнюю обработку/отчет.

● extensions ‑ работа с расширениями конфигурации.

● generation-id ‑ получить идентификатор «поколения» метаданных.

● load-cfg ‑ загрузка конфигурации из файла.

● load-config-from-files ‑ загрузка конфигурации из XML-файлов.

● load-external-data-processor-or-report-to-files ‑ загрузить из XML-файлов внешнюю обработку/отчет.

● manage-cfg-support ‑ снятие конфигурации с поддержки.

● mobile-app-write-file ‑ сохранить на диск конфигурацию мобильного приложения.

● mobile-client-digi-sign ‑ сформировать цифровую подпись конфигурации мобильного клиента.

● mobile-client-write-file ‑ сохранить на диск конфигурацию мобильного клиента.

● sign-cfg ‑ выполнить цифровую подпись конфигурации.

● update-db-cfg ‑ обновление конфигурации базы данных.

● infobase-tools ‑ получение сервисной информации об информационной базе (подробнее см. здесь):

● data-separation-common-attributes-list ‑ получение списка имен общих реквизитов.

● debug-info ‑ получение информации об отладчике.

● dump-ib ‑ выгрузка информационной базы в файл.

● erase-data ‑ удаление данных информационной базы.

● restore-ib ‑ загрузка конфигурации из файла.

Файлы и каталоги, созданные через SFTP, размещаются в каталоге данных пользователя.

Смотри также:

● Конфигуратор в режиме агента (см. здесь).

Автономный сервер позволяет управлять доступностью некоторых своих возможностей. Для этого предназначены специальные параметры командной строки запуска или параметры секции features конфигурационного файла. Доступно управление следующими возможностями:

● Шлюз прямого подключения (по протоколу TCP/IP) к автономному серверу. Если данный шлюз выключен, то становится недоступна возможность подключения толстым клиентом и, в общем случае, любым клиентским приложением, которое подключается с использованием протокола TCP/IP. Также в этом случае становится недоступна отладка по протоколу TCP/IP.

● Включение шлюза: --enable-direct-gate или параметр direct-gate: true секции features конфигурационного файла автономного сервера.

● Выключение шлюза: --disable-direct-gate или параметр direct-gate: false секции features конфигурационного файла автономного сервера.

● По умолчанию шлюз включен.

● Шлюз подключения к автономному серверу по протоколу HTTP. Если данный шлюз выключен, то становится недоступна возможность подключения любым клиентским приложением (в том числе веб-клиент, мобильный клиент и т. д.) по протоколу HTTP. Также в этом случае становится недоступна отладка по протоколу HTTP.

● Включение шлюза: --enable-http-gate или параметр http-gate: true секции features конфигурационного файла автономного сервера.

● Выключение шлюза: --disable-http-gate или параметр http-gate: false секции features конфигурационного файла автономного сервера.

● По умолчанию шлюз включен.

● Шлюз подключения к информационной базе по протоколу SSH и возможность выполнять команды с использованием этих протоколов.

● Включение шлюза: --enable-ssh-gate или параметр ssh-gate: true секции features конфигурационного файла автономного сервера.

● Выключение шлюза: --disable-ssh-gate или параметр ssh-gate: false секции features конфигурационного файла автономного сервера.

● По умолчанию шлюз включен.

● Управляет возможностью использования расширенной функциональности Конфигуратора. Если данная возможность отключена, то становится невозможно использовать некоторые возможности автономного сервера, например, запись конфигураций для мобильных устройств в файл.

● Включение шлюза: --enable-extended-designer-features или параметр extended-designer-features: true секции features конфигурационного файла автономного сервера.

● Выключение шлюза: --disable-extended-designer-features или параметр extended-designer-features: false секции features конфигурационного файла автономного сервера.

● По умолчанию шлюз выключен.

Смотри также:

● Шлюзы автономного сервера (см. здесь).

● Управление возможностями автономного сервера (см. здесь).

Автономный сервер поддерживает все протоколы отладки (включая внешний сервер отладки при использовании протокола HTTP). Для того, чтобы включить возможность отладки, следует использовать команду командной строки --debug или секцию debug конфигурационного файла. При этом следует иметь ввиду, что возможности отладки по протоколу TCP/IP или HTTP, зависят от доступности соответствующих шлюзов в конфигурации автономного сервера.

В общем случае для того, чтобы включить отладку в автономном сервере, следует в командной строке запуска сервера указать команду --debug. В этом случае способ отладки определяется настройками автономного сервера. Выбор способа отладки выполняется в следующем порядке:

1. Отладка по протоколу TCP/IP, если не отключен шлюз прямого подключения.

2. Отладка по протоколу HTTP, если не отключен шлюз подключения по протоколу HTTP.

3. Отладка по протоколу HTTP с использованием внешнего сервера отладки, если параметры внешнего сервера отладки указаны в командной строке (--debug-server-url) или конфигурационном файле.

4. Отладка выключена во всех остальных случаях.

Таким образом, если для автономного сервера включен режим отладки по умолчанию, без уточнения режима отладки, а также включены оба шлюза (прямого подключения и по протоколу HTTP), то отладка будет осуществляться по протоколу TCP/IP. Если в такой ситуации необходимо выбрать другой способ отладки ‑ необходимо это явно указать с помощью значения команды --debug (и указания сопутствующих команд) или в конфигурационном файле.

Также следует помнить, что использовать оба протокола отладки (TCP/IP и HTTP) одновременно невозможно. Поэтому, если требуется использовать конкретный вид отладки, рекомендуется явно указать этот вид отладки в значении команды --debug или конфигурационном файле.

Смотри также:

● Секция gates конфигурационного файла автономного сервера (см. здесь).

● Секция debug конфигурационного файла автономного сервера (см. здесь).

Для того, чтобы автономной сервер использовал внешний сервер отладки, необходимо запустить внешний сервер отладки и указать его (сервера отладки) подключения в настройках автономного сервера. Схема отладки выглядит следующим образом:

1. Запускается сервер отладки.

2. Запускается автономный сервер, для которого указывается возможность использования сервера отладки, запущенного на предыдущем шаге. Конфигурация информационной базы автономного сервера должна в точности соответствовать конфигурации, которую планируем отлаживать.

3. Информационная база автономного сервера будет использоваться только для получения структуры конфигурации и исходных текстов, данные в процессе отладки будет получаться из отлаживаемой базы данных.

При запуске автономного сервера следует указать расположение сервера отладки. Это выполняется с помощью команды --debug-server=<dbgs-адрес>. Адрес сервера отладки формируется из имени компьютера, на котором запускается сервер отладки, и номера порта, указанного при запуске. Для запуска по умолчанию адрес будет http://localhost:1550.

Автономный сервер может быть запущен с указанием адреса сервера отладки при физически не запущенном сервере отладки. Собственно сервер отладки можно запустить позже, когда возникнет необходимость отладки.

Смотри также:

● Отладка прикладного решения (см. здесь).

С помощью утилиты управления автономным сервером (ibcmd) предоставляется возможность выгрузить информационную базу в dt-файл. Для этого следует использовать команду вида:

ibcmd infobase dump --dbms=mssqlserver --database-server=dbServerName --database-user=dbUser --database-password=dbUserPassword --database-name=docs-db --data="d:\ss-data\dbName-data" 1cv8.dt

При выполнении данной команды необходимо быть уверенным, что с базой данных, которая выгружается в dt-файл, не должно быть никаких подключений. Данное ограничение включает в себя запрет на работу с выгружаемой информационной базой нескольких серверных приложений (как автономных, так и обычных). В противном случае возможно нарушение целостности создаваемого файла выгрузки информационной базы (dt-файл).

Кроме того, следует помнить, что выгрузка информационной базы не является средством резервного копирования информационной базы (подробнее см. здесь). Для выполнения резервной копии базы данных следует пользоваться соответствующими инструментами (см. здесь).

Данный раздел содержит примеры управления и запуска автономного сервера. Следует понимать, что примеры, приведенные в данном разделе, не являются законченными. Они предназначены для демонстрации некоторых возможностей работы с автономным сервером.

При настройке параметров работы автономного сервера, рекомендуется всегда явным образом задавать имя информационной базы, с которой работает автономной сервер. Это следует делать с помощью:

● Параметра infobase.name файла конфигурации автономного сервера.

● Команда командной строки --name.

В примерах может отсутствовать явное указание имени информационной базы, что сделано с целью уменьшения размера примеров. При выполнении реальных действий, указывать имя информационной базы настоятельно рекомендуется.

Также следует учитывать, что для выполнения команд утилиты управления (как и для собственно автономного сервера) необходимо полностью идентифицировать используемую информационную базу и каталог данных информационной базы одним из следующих способов:

● С помощью команд командной строки запуска (для работы на локальном компьютере).

● Указав в командной строке запуска путь к конфигурационному файлу автономного сервера (для работы на локальном компьютере).

● Указав экземпляр автономного сервера на локальном или удаленном компьютере.

Операции с информационной базой требуют аутентификации. Пользователь и пароль указываются с помощью команд командной строки --user и --password. В примерах всегда будут использоваться пользователь ibuser с паролем 123. Очевидно, что в реальных системах такой пароль недопустим из соображений безопасности.

Смотри также:

● Конфигурационный файл автономного сервера (см. здесь).

ibcmd server config init --dbms=postgresql --database-server=dbServerName --db-user=dbUser --database-password=dbUserPassword --database-name=dbName --name=docsIB --http-base=/webAccess

В результате выполнения данной команды в стандартный поток вывода (stdout) будет выведен следующий конфигурационный файл:

server:
  address: localhost
  port:
database:
  dbms: PostgreSQL
  server: dbServerName
  name: dbName
  user: dbUser
  password: dbUserPassword
infobase:
  id: 7b88938e-5aa8-4933-afea-8a9ec121724f
  name: docsIB
  distribute-licenses: yes
  schedule-jobs: allow
http:
  base: /webAccess

Эту информацию можно записать в файл с помощью команды --out утилиты ibcmd или с помощью переадресации stdout в файл: > file.ext.

Также стоит отметить, что автономный сервер, запущенный с таким конфигурационным файлом, будет запускать веб-клиента при обращении по адресу http://localhost:8314/webAccess.

Смотри также:

● Конфигурационный файл автономного сервера (см. здесь).

ibcmd server config import --cluster-data="d:\1C srvinfo" --name=demoma --out=d:\ss-cfgs\demoma.yml

В результате выполнения данной команды в конфигурационном файле d:\ss-cfgs\demoma.yml будет размещена следующая конфигурация:

server:
  address: localhost
  port: 8314
database:
  dbms: MSSQLServer
  server: <имя сервера>
  name: <имя базы данных>
  user: sa
  password: <пароль пользователя>
infobase:
  id: 1a39d42c-4da6-4f1c-bd78-98884d27578b
  name: demoma
  distribute-licenses: yes

Данная команда выполнила импорт информации об информационной базе demoma из кластера, каталог данных которого расположен по адресу d:\1C srvinfo. Таким образом, если вам нужно запустить несколько информационных баз, которые уже зарегистрированы в работающем кластере, с помощью автономного сервера, параметры этих баз не обязательно переносить в конфигурационный файл вручную.

Одновременно с импортом информации об информационной базе можно импортировать данные публикации. Для этого следует в командной строке импорта указать путь к файлу default.vrd (параметр --publication):

ibcmd server config import --cluster-data="d:\1C srvinfo" --name=demoma --publication=c:\inetpub\wwwroot\demoma\default.vrd --out=d:\ss-cfgs\demoma.yml

В указанном примере будет выполнен импорт информационной базы demoma и параметров публикации, указанных в файле c:\inetpub\wwwroot\demoma\default.vrd. Результат импорта будет представлять собой единый конфигурационный файл автономного сервера. Следует помнить, что механизм импорта файла публикации игнорирует командную строку доступа к информационной базе, которая указана в атрибуте ib элемента point файла default.vrd. Пользователь, выполняющий импорт, должен осмысленно указывать параметры импортируемой базы и файла публикации.

Смотри также:

● Конфигурационный файл автономного сервера (см. здесь).

ibcmd server config init --database-path="D:\ss-data\file-db\db-data" --name=docsIB --http-base=/webAccess --out="D:\ss-data\file-db\file-db.yml"
ibcmd infobase create --config="D:\ss-data\file-db\file-db.yml" --load="D:\Cfgs\MyApp\1Cv8.cf" --data="D:\ss-data\file-db"

Данный пример состоит из двух шагов:

1. Первая строка формирует конфигурационный файл автономного сервера (ibcmd server config init).

2. Вторая строка выполняет создание информационной базы (и файла базы данных) на основании файла конфигурации (ibcmd infobase create).

В общем случае, создание информационной базы на основании файла конфигурации можно выполнить и одной командой. В данном случае выбор способа решения зависит от нескольких параметров, например, параметры базы задаются в одном месте информационной системы, а база создается в другом, но с использованием конфигурационного файла, созданного на предыдущем шаге. Если требуется только создать информационную базу из командной строки на основе файла конфигурации, это действие может быть выполнено следующим образом:

ibcmd infobase create --data="D:\ss-data\fs-data" --database-path="D:\ss-data\file-db\db-data" --load="D:\Cfgs\MyApp\1Cv8.cf"

В результате выполнения любого из вышеприведенных примеров, в каталоге D:\ss-data\fs-db\db-data будет создана информационная база, а работа системы будет сопровождаться следующим выводом в стандартный поток вывода (stdout):

[ INFO] Создание информационной базы...
[ INFO] Создание информационной базы успешно завершено
[ INFO] Загрузка конфигурации...
[ INFO] Загрузка конфигурации успешно завершена

Если к моменту выполнения команды файл базы данных (1Cv8.1CD) будет создан ‑ выполнение команды завершится с ошибкой.

Создание клиент-серверного варианта информационной базы принципиально не отличается от создания файлового варианта. Очевидно, что в случае клиент-серверного варианта будет требоваться большее количество параметров:

ibcmd infobase create --dbms=mssqlserver --database-server=dbServerName --db-user=dbUserName --database-password=dbUserPassword --database-name=my-db --name=docsIB --data="D:\ss-data\cs-data" --create-database --load="D:\Cfgs\MyApp\1Cv8.cf" --apply

В результате в Microsoft SQL Server будет создана база данных my-db, в которую будет загружена конфигурация из файла D:\Cfgs\MyApp\1Cv8.cf. Повторное выполнение команды приведет к ошибке, т. к. база данных уже будет существовать.

Также следует помнить, что команда создания информационной базы из файла конфигурации не приводят к созданию конфигурации базы данных. Для того чтобы структура базы данных соответствовала используемой (для создания информационной базы) конфигурации, необходимо использовать специальный параметр, отвечающий за обновление конфигурации базы данных:

ibcmd infobase create --dbms=mssqlserver --database-server=dbServerName --db-user=dbUser --database-password=dbUserPassword --database-name=my-db --name=docsIB --data="D:\ss-data\cs-data" --create-database --load="D:\Cfgs\MyApp\1Cv8.cf" --apply --force

В этом случае вывод будет содержать информацию об обновлении конфигурации базы данных:

[INFO] Создание информационной базы...
[INFO] Создание информационной базы успешно завершено
[INFO] Загрузка конфигурации...
[INFO] Загрузка конфигурации успешно завершена
[INFO] Обновление конфигурации базы данных...
[INFO] Проверка корректности метаданных...
[INFO] Обработка структуры базы данных...
[INFO] Обработка данных
…
[INFO] Сбор служебной информации...
…
[INFO] Принятие изменений...
[INFO] Построение индекса справки...
[INFO] Построение индекса справки успешно завершено
[INFO] Обновление конфигурации базы данных успешно завершено

ibcmd infobase config load --user=ibuser --password=123 --dbms=mssqlserver --database-server=dbServerName --db-user=dbUser --database-password=dbUserPassword --database-name=docs-db --data="D:\ss-data\cs-data" --name=docsIB 1Cv8.cf
ibcmd infobase config apply --user=ibuser --password=123 --dbms=mssqlserver --database-server=dbServerName --db-user=dbUser --database-password=dbUserPassword --database-name=docs-db --name=docsIB --data="D:\ss-data\cs-data" --force

Первая команда выполнит собственно загрузку конфигурации в информационную базу, а вторая ‑ обновит конфигурацию базы данных (с выполнением, при необходимости, реструктуризации базы данных).

Результат выполнения команд:

>ibcmd infobase config load …
[INFO] Загрузка конфигурации...
[INFO] Загрузка конфигурации успешно завершена
>ibcmd infobase config apply …
[INFO] Обновление конфигурации базы данных...
[INFO] Проверка корректности метаданных...
[INFO] Принятие изменений...
[INFO] Создано поколение конфигурации: 99bf6cd4045c8f43a86244a0dab4f24000000000
[INFO] Обновление конфигурации базы данных успешно завершено

Следует обратить внимание, что файл выгрузки в данной команде указывается без какого-либо именованного параметра, последним значением в командной строке. Такая же особенность будет у всех команд, которые требуют файл в качестве входного параметра.

Информация о поколении конфигурации может пригодиться в тех случаях, когда будет необходимо проверить, что конфигурация не изменялась относительно последнего обновления конфигурации. Поколение конфигурации, которое получено в результате обновления (ibcmd infobase config apply), будет расположено в журнале обновления (строка [INFO] Создано поколение конфигурации:), а текущее поколение конфигурации можно получить с помощью команды ibcmd infobase config generation-id. Информация о созданном поколении конфигурации также будет выводиться при выполнении команды config update-db-cfg агента конфигуратора или при подключении к автономному серверу по протоколу SSH.

Для управления возможностью динамического обновления информационной базы служит команда --dynamic команды ibcmd infobase config apply. С помощью этого параметра можно запретить динамическое обновление или, наоборот, принудительно выполнить такое обновление.

ibcmd infobase create --dbms=mssqlserver --database-server=dbServerName --db-user=dbUser --database-password=dbUserPassword --database-name=docs-db --data="D:\ss-data\cs-data" --create-database --restore=1cv8.dt

Результат выполнения данной команды:

[ INFO] Создание информационной базы...
[ INFO] Создание информационной базы успешно завершено
[ INFO] Загрузка информационной базы...
[ INFO] Загрузка информационной базы успешно завершена

В результате выполнения данной команды будут выполнены следующие действия:

● В СУБД Microsoft SQL Server с именем dbServerName будет создана база данных docs-db.

● Для доступа к СУБД используется пользователь dbUser, для которого задан пароль dbUserPassword.

● В случае отсутствия следует создать базу данных.

● После создания базы данных в нее следует загрузить информацию из файла 1cv8.dt, который размещен в каталоге, откуда выполняется запуск приведенной команды.

ibcmd.exe infobase restore --user=ibuser --password=123 --dbms=mssqlserver --database-server=dbServerName --db-user=dbUser --database-password=dbUserPassword --database-name=docs-db --data="D:\ss-data\cs-data" --database-name=dbName .\1cv8.dt

Результат выполнения данной команды:

[ INFO] Загрузка информационной базы...
[ INFO] Загрузка информационной базы успешно завершена

Следует обратить внимание, что dt-файл в данной команде указывается без какого-либо именованного параметра, последним значением в командной строке.

Если необходимо загрузить dt-файл в информационную базу, которая в данный момент обслуживается автономным сервером, то для выполнения такого действия необходимо будет выполнить одну из следующих команд:

ibcmd.exe --pid=ProcessID infobase restore .\1cv8.dt
ibcmd.exe --remote=ssh://Server1C:8282 infobase restore .\1cv8.dt

Эти команды выполняют одно и тоже действие, но различаются тем, где находится экземпляр автономного сервера, который будет выполнять загрузку информационной базы из dt-файла:

● Указана команда --pid. В этом случае автономный сервер работает на том же компьютере, что утилита ibcmd. Значение ProcessID означает номер процесса операционной системы запущенного автономного сервера.

● Указана команда --remote. В этом случае автономный сервер работает на компьютере, который отличается от компьютера, на котором запускается утилита ibcmd. Значение ssh://Server1C:8282 означает адрес настроенного SSH-шлюза автономного сервера, который должен выполнить загрузку информационной базы.

Смотри также:

● Управление автономным сервером (см. здесь).

● Настройка доступа к автономному серверу по протоколу SSH (см. здесь).

Примеры в данном разделе предполагают, что в конфигурационном файле автономного сервера (если такой будет использоваться) не отключены используемые шлюзы. Если требуемый шлюз отключен, то следует в командной строке запуска автономного сервера явно включить этот шлюз.

Чтобы выполнять отладку с использованием автономного сервера по протоколу TCP/IP, необходимо запустить автономный сервер следующим образом:

ibsrv --dbms=mssqlserver --database-server=dbServerName --db-user=dbUser --database-password=dbUserPassword --database-name=docs-db --name=docs-db --data="D:\ss-data\cs-data" --debug=tcp

При необходимости использования отладки по протоколу HTTP, команда будет выглядеть следующим образом:

ibsrv --dbms=mssqlserver --database-server=dbServerName --db-user=dbUser --database-password=dbUserPassword --database-name=docs-db --name=docs-db --data="D:\ss-data\cs-data" --debug=http

Пароль пользователя СУБД, от имени которого работает автономный сервер, размещается в конфигурационном или командном файле в открытом виде. Эта ситуация может оказаться недопустимой.

В этом случае может помочь специальная команда (--request-db-pwd), которая позволит получить пароль из стандартного потока ввода (stdin).

ibsrv --dbms=mssqlserver --database-server=dbServerName --db-user=dbUser --database-name=docs-db --name=docsIB --data=d:\ss-data\cs-data --request-database-password

В случае указания такой команды автономный сервер будет ожидать пароль пользователя СУБД (dbUser в примере выше) из стандартного потока ввода. Следует помнить, что сервер не будет никаким образом приглашать пользователя к выполнению ввода.

Другим вариантом указания пароля будет являться перенаправление в stdin автономного сервера какого-либо файла или вывода другой программы:

ibsrv --dbms=mssqlserver --database-server=dbServerName --db-user=dbUser --name=docsIB --database-name=docs-db --data=d:\ss-data\cs-data --request-database-password < sqlpwd.txt

Различные сервисы автономного сервера используют дисковый накопитель для размещения служебных данных во время работы автономного сервера. Разные сервисы используют для своей работы различные каталоги. Базовым каталогом для размещения служебных данных выступает каталог данных автономного сервера: по умолчанию служебные каталоги размещаются в этом каталоге. Каталог данных имеет размещение по умолчанию (см. здесь, параметр --data), но рекомендуется указывать для каждой информационной базы, работающей под управлением автономного сервера, свой, уникальный, каталог данных. Это связано с тем, что служебные данные, которые автономный сервер хранит в каталоге данных (и вложенных каталогах), являются специфичными для информационной базы. Указание этого же каталога для работы с другой информационной базы может привести к непредсказуемым последствиям вплоть до невозможности нормальной эксплуатации системы.

Изменяя расположение каталога данных ‑ изменяется расположение всех остальных каталогов, расположение которых не задано явно. В тоже время автономный сервер позволяет указать индивидуальное расположение различных служебных каталогов:

«Публикация» информационной базы для работы через веб-сервер выполняется автоматически при запуске автономного сервера. В качестве веб-сервера выступает сам автономный сервер. При этом автономный сервер предоставляет все возможности доступа через веб-сервер, что и обычная публикация: веб-клиент, тонкий клиент через веб-сервер, интернет-сервисы, стандартный интерфейс OData. Возможность использовать тот или иной способ доступа управляется параметрами конфигурационного файла, с помощью которого предоставляется возможность управлять параметрами публикации.

Часть параметров публикации можно изменять с помощью командной строки запуска автономного сервера:

● --http-base. Позволяет указать путь к ресурсу, который будет использоваться для доступа к приложению. По умолчанию используется путь /, что означает возможность войти в веб-клиент по адресу http://localhost:8314 (для параметров по умолчанию). Если указать значение для данного параметра, например --http-base=/standalone/example, то для доступа к приложению нужно будет использовать адрес http://localhost:8314/standalone/example.

● --http-port. Сетевой порт, который будет использоваться для доступа к приложению. По умолчанию используется значение 8314.

● --http-address. Данный параметр описывает, какой сетевой интерфейс компьютера будет использоваться для доступа к публикации. По умолчанию используется значение localhost. Другими значениями могут выступать:

● any ‑ использовать все доступные сетевые интерфейсы.

● xxx.xxx.xxx.xxx ‑ для доступа будет использовать сетевой интерфейс, которому назначен указанный адрес IPv4.

● xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx ‑ для доступа будет использовать сетевой интерфейс, которому назначен указанный адрес IPv6.

Рассмотрим простой пример. Допустим, у нас есть автономный сервер, работающий с файловым вариантом информационной базы. Этот автономный сервер запускается командной строкой вида:

ibsrv --database-path="c:\db\ss-data\demo"

При этом информационная база этого сервера будет доступа по адресу http://localhost:8341 при обращении с компьютера, на котором выполняется автономный сервер.

Допустим, необходимо обеспечить веб-доступ к этой информационной базе по адресу http://<pc-addr>:8080/standalone/demo. Для достижения результата будет необходимо запустить автономный сервер следующей командной строкой:

ibsrv --database-path="c:\db\ss-data\demo" --http-base=/standalone/demo --http-port=8080 --http-address=<pc-addrt>

В данном примере текст <pc-addr> подразумевает указание одного из сетевых интерфейсов компьютера, на котором работает автономный сервер.

Также следует помнить, что автономный сервер предоставляет возможность обслуживать несколько публикаций одной информационной базы. Такая возможность доступна только посредством указания соответствующих параметров в конфигурационном файле автономного сервера.

Пример конфигурационного файла:

server:
 address: localhost
database:
 dbms: PostgreSQL
 server: dbServerName
 name: dbBase
 user: postgres
 password: postgres
infobase:
 name: clusterDbName
 distribute-licenses: yes
 schedule-jobs: deny
http:
 - base: /lk
   odata:
    publish: true
    reuse-sessions:
     mode: dontuse
 - base: /partner
   web-services:
    service:
     - name: RemoteManagement
       alias: RemoteManagment.1cws
       publish: true
       reuse-sessions:
        mode: autouse
   odata:
    publish: true
    reuse-sessions:
     mode: dontuse

Смотри также:

● Публикация информационной базы (см. здесь).

● Конфигурационный файл автономного сервера (см. здесь).

● Секция http конфигурационного файла автономного сервера (см. здесь).

Настройка работы с разделителями выполняется с помощью конфигурационного файла автономного сервера. Для настройки необходимо использовать секцию http.zones конфигурационного файла (см. здесь).

Пример:

http:
 - base: /clients
   zones:
    - specify: false
      safe: false
    - specify: true
      safe: false

В данном примере рассматривается организация веб-доступа к информационной базе со следующим параметрами:

● Базовый каталог для доступа: /clients.

● Информация по разделителям:

● В прикладном решении используются два разделителя.

● Первый разделитель не должен быть указан в URL доступа (параметр specify равен значению false) и его изменение из встроенного языка невозможно (параметр safe равен значению false).

● Второй разделитель должен быть указан в URL доступа (параметр specify равен значению true) и его изменение из встроенного языка невозможно (параметр safe равен значению false).

Для того, чтобы получить список разделителей для информационной базы, которую обслуживает конкретный экземпляр автономного сервера, необходимо выполнить следующую операцию:

ibcmd --pid=ProcessID infobase config data-separation list

В этой команде ProcessID ‑ является идентификатором процесса экземпляра автономного сервера. Утилита управления подключится к информационной базе этого сервера и получит из нее список разделителей.

Смотри также:

● Механизм разделения данных (см. здесь).

● Конфигурационный файл автономного сервера (см. здесь).

Автономный сервер позволяет выполнить выгрузку и загрузку конфигурации в файлы XML. Выгрузка и загрузка всегда выполняются в иерархическом формате. Линейный формат выгрузки не поддерживается автономным сервером. Поддерживаются оба варианта выгрузки и загрузки конфигурации (частичная и полная).

Для полной выгрузки необходимо применить следующую команду:

ibcmd infobase config export --user=ibuser --password=123 --config=config.yml d:\cfg_xml

Следующая команда позволит выполнить синхронизацию конфигурации и каталога выгрузки:

ibcmd infobase config export --user=ibuser --password=123 --sync --config=config.yml d:\cfg_xml

Обновление выгрузки в каталоге d:\cfg_xml будет выполнено, если:

● Каталог d:\cfg_xml содержит файл ConfigDumpInfo.xml.

● Совпадают уникальные идентификаторы корневых объектов в конфигурации и в файле ConfigDumpInfo.xml.

● Совпадают номера версий формата выгрузки в XML у конфигурации и файла ConfigDumpInfo.xml.

● В каталоге d:\cfg_xml выгрузка находится в иерархическом формате.

● Синхронизация не требует полной выгрузки конфигурации.

При загрузке выполняется автоматическое определение формата загружаемой выгрузки. Для полной загрузки конфигурации из файлов необходимо применить следующую команду:

ibcmd infobase config import --user=ibuser --password=123 --config=config.yml d:\cfg_xml

Следует понимать, что данная команда полностью заменит конфигурацию в информационной базе, которая описана конфигурационным файлом config.yml.

Для частичной загрузки конфигурации можно воспользоваться следующей командой:

type d:\fileList.lst|ibcmd infobase config import files --user=ibuser --password=123 --http-base-dir d:\cfg_xml

При этом:

● Будут загружены только те файлы, которые перечислены в файле d:\fileList.lst.

● Файл d:\fileList.lst содержит список полных путей к загружаемым файлам. В одной строке расположен полный путь к одному файлу.

● Каталог d:\cfg_xml содержит каталог с выгрузкой.

Смотри также:

● Выгрузка/загрузка конфигурации в файлы (см. здесь).

● Конфигурационный файл автономного сервера (см. здесь).

ibcmd --pid=ProcessID session list

В этой команде ProcessID ‑ является идентификатором процесса экземпляра автономного сервера. Утилита управления подключится к информационной базе этого сервера и получит список сеансов этой информационной базы.

Смотри также:

● Сеансы и соединения (см. здесь).

ibcmd --remote=ssh://Server1C:8282 lock list

В этой команде ssh://Server1C:8282 ‑ это адрес SSH-шлюза, который может использоваться для доступа к конкретному экземпляру автономного сервера.

Смотри также:

● Настройка доступа к автономному серверу по протоколу SSH (см. здесь).

ibcmd --pid=ProcessID infobase config extension create --user=ibuser --password=123 --name=PatchExtension1 --name-prefix=patchEx1 --purpose patch
ibcmd --pid=ProcessID infobase config load --user=ibuser --password=123 --extension=PatchExtension1 patchExt1.cfe
ibcmd --pid=ProcessID infobase config apply --user=ibuser --password=123 --extension=PatchExtension1 --force

В этой команде ProcessID ‑ является идентификатором процесса экземпляра автономного сервера.

Для того, чтобы выполнить миграцию информационной базы между двумя SQL-серверами, не прибегая к промежуточному формату выгрузки (dt-файл), следует выполнить команду следующего вида:

ibcmd infobase replicate --data=d:\ss-data\cs-data --dbms=MSSQLServer --database-server=localhost --database-name=dbMsSql --database-user=msUser --database-password=123 --target-dbms=PostgreSQL --target-database-server=localhost --target-database-name=dbPgSql --target-database-user=pgUser --target-database-password=123 --target-create-database

В данном примере:

● Каталог данных автономного сервера: d:\ss-data\cs-data.

● СУБД, источник: Microsoft SQL Server.

● СУБД, приемник: PostgreSQL.

● Информационная база, источник: dbMsSql.

● Информационная база, приемник: dbPgSql.

● Обе СУБД работают на локальном компьютере.

● Необходимо создать базу данных в приемнике, если этой базы нет.

● Параметры доступа к СУБД (имя пользователя и пароль) приведены исключительно в демонстрационных целях. В производственных базах данных использовать такие параметры доступа настоятельно не рекомендуется.